1. Field of the Invention
The present invention relates to a method, system and program for detecting and protecting communication code information while still allowing this information to be changed.
2. Description of the Related Art
Personal computers and workstations have become standard work tools in most office environments. To further improve the usefulness of the computer systems, most office computer systems have been linked together into an office Local Area Network (LAN). The Local Area Network allows the computer users at different computer systems to easily share information with each other. The network also allows the computer users to share computer hardware such as printers and modems. Many local area networks consist of a centralized network hub that is coupled to all the end computer systems.
This proliferation of network devices has resulted in very large and difficult-to-manage computer networks. For example, a computer network manager may be responsible for installing and maintaining numerous network hubs, network printers, network bridges, routers, gateways, file servers, and remote access servers. To simplify the task of managing all these network devices, network management systems have been devised.
To simplify the management of a large number of network devices coupled to a computer network the Simple Network Management Protocol (SNMP) was created. The Simple Network Management Protocol is a standardized protocol for sending network management commands to network devices and receiving status information from the network devices. To manage a computer network using the Simple Network Management Protocol, a network manager runs a network manager program on a workstation coupled to the network. The network manager program displays the status information received from the SNMP compatible network devices coupled to the network. To control the network devices, the network manager program sends out SNMP commands.
Using SNMP, network administrators can address queries and commands to network nodes and devices. SNMP monitors network performance and status; controls operational parameters; and reports, analyzes and isolates faults. The protocol accomplishes these functions by transporting management information between “Managers” and “Agents”.
SNMP defines the following three basic components:                1. An Agent is a component housed within a managed network device such as a printer, host, gateway, or terminal server. Each Agent stores management data and responds to the Manager's requests for this data, and may send a “TRAP”, a special unsolicited SNMP message, to the Manager after sensing a pre-specified condition.        2. A Manager is a component housed within a Network Management Station. The Manager queries/controls Agents using various SNMP commands.        3. A Management Information Base (MIB) is a managed object database, accessible to Agents and manipulated via SNMP for network management application.        
To carry out the Agent's and Manager's duties, SNMP specifies five types of commands or verbs, called Protocol Data Units (PDUs): GetRequest, GetNextRequest, SetRequest, GetResponse and Trap. Agents inspect and retrieve the management data after receiving either a GetRequest or a GetNextRequest PDU from a Manager. Managers use GetRequest for retrieving single values of the managed objects. The GetNextRequest is issued by the Manager to begin a primitive block transfer and the Agent returns the selected data with a GetResponse verb. Managers use SetRequest commands for instructing Agents to alter MIB variables while Traps are unsolicited messages sent by Agents to Managers after sensing pre-specified conditions.
SNMP is advantageous as a communication protocol because neither the Agent nor Manager rely on the other to continue operating. Thus, one may fail, and the other would carry on. SNMP further does not require the establishment of a communication path prior to the transmission of data. As a result, with SNMP, there is no guarantee that a transmission was received. Although most messages do transmit successfully, those that do not cannot be re-transmitted. On the other hand, SNMP's simplicity and connectionless communication also produce a degree of robustness. Neither the Manager nor the Agent relies on the other for its operation.
A primary protocol used by SNMP for communication is the User Datagram Protocol (UDP). Under UDP, a session is not established before the transmission of data (that is, there is no three-way handshake, as used with transmission control protocol, (TCP)). This means that a logon with a user ID and password is not performed prior to transmission of data. This can be considered a security hole because the software that is receiving a datagram has no way to verify the identity of the software that sent the datagram.
SNMP does however provide a simple form of security by utilizing what is known as a community. During installation of the Manager and Agent software, the installer enters one or more community names. For example a community name could be the word public. The network management software is then configured to only accept datagrams from or send datagrams to specific communities. In addition to the community names, the network software can be configured to only allow the receipt of datagrams from specific IP addresses. Agents are configured with the IP addresses of network Managers to which they can send unsolicited messages.
Thus in order to communicate with a device, such as a printer, using SNMP, an application must use some SNMP community name. Most applications use either the community name “public” or ask the user to provide a community name. However, there are problems associated with this.
First, “public” often does not have write privileges. Certain SNMP commands, such as SetRequest, require data to be written on the MIB associated with the managed device. With some applications, the “public” community name will not permit this data to be written on the MIB.
A second problem is that many devices do not support the “public” community name at all, and thus would not be able to communicate.
Asking the user to provide the community name often does not help, since many users are not system administrators and thus do not know the proper community name to use in order to communicate with a particular device.
Another problem associated with the use of community names is that they are used by some system administrators in a way similar to passwords, keeping them secret from even the other users of the network. These administrators disable the community names installed in the managed devices by the manufacturers and insert their own “secret” community name for the network in question. However because applications typically display the community names, the ability to retain their secrecy is usually not effective.
Thus it would be desirable for Manager applications, such as for example, printer port monitor applications, to have the capability of automatically detecting community names. Moreover it would be desirable that such applications have the capability of accepting and using community names without disclosing them to users.